Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web services have been a driving force in advancing such communications between computer systems and are turning the way software built and used inside-out.
Web services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web services may be invoked over the Internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (eXtensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although web services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication on a web service network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., web services) at a server computer system (hereinafter referred to as a “server,” “service,” or “web service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein the service responds with a response message providing the desired information. Of course, other messaging patterns between client and service may be available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, kick-push, queuing, and others. In addition, there may be other procedures needed for accessing the service resources, such as authentication and validation mechanisms.
Regardless of the type of message patterns and or procedures used to access a service, web services provide interoperability in a platform agnostic way because both clients and services agree on a basic contract. Represented by a mixture of machine-readable and human languages, such contracts define, among other things, the operations—units of functionality—offered by the web service and/or the format of the messages passed to and/or returned by each operation when invoked. Network Protocol Description Languages (e.g., WSDL) provide an overall wrapper or specification for describing web service contracts in a common or standard language. Such specifications make it easy for developers and developer tools to create and interpret contracts; and also have extensive tooling suites, which in large part accounts for their popularity.
A contract for a web service may either be written independently of the service implementation (e.g., one that includes business logic from another organization) or may be produced by some automated means to reflect the behavior of an existing service. Increasingly, developers need the ability to precisely state the contract independently of the implementation. For example, interoperability scenarios between multiple enterprises, or groups or teams within the same enterprise, often use a “contract-first” or “contract-driven” development strategy. In such instances, once a contract has been agreed upon between the participating parties, specific implementation(s) of the web service can be created to conform to the business logic of the various endpoints. Existing tools allow the generation of a “skeleton” web service implementation based on the web service contract, which then allow a developer to complete the details of the business logic for each operation provided by the service. Typically, such skeleton implementations comprise a class for the service with methods for each operation as defined by the contract. Further, each method's signature describes the messages sent to and/or returned by the operation, with additional classes created where required to describe message data structures referenced in the signature.
Often times, however, the web service contract changes after the implementation of the web service has begun. For example, the contract may need changes to meet new or modified business requirements or in the case where developers use iterative or incremental development strategies. Accordingly, changes to the web service contract typically require changes to both the skeleton (the methods, signatures, and classes or data structures) and the business logic in order to conform to the updated service contract. Current tools, however, do not support updating the web service implementation to accommodate changes to the contract.
Accordingly, a developer has few options available for modifying a web service implementation to conform to the updated web service contract. For example, the developer will typically either: (1) recreate a new service implementation from the revised contract using existing tools (e.g., skeleton tool) and manually migrate those aspects of the prior service implementation they wish to retain; or (2) manually edit the existing implementation code to make the changes necessary to conform to the revised contract. Depending on the scope of the change, both approaches are labor intensive and subject to human error. In addition, these approaches may require that the developer have intimate knowledge of the NPDL language (e.g., WSDL) and/or the schema used (e.g., XML schema) so that they understand the nature of the change and how to map this to their implementation. Due to the complexities in such languages and schemas, however, such modifications are beyond the typical skill set of most developers.